猴子敏捷之術，從來不是那些時髦的術語或會議，那敏捷之術到底是什麼？也許會是足以改變職涯的故事。在 Project Banana Paradise AI 計畫穩定下來後，一隻資深程序猿在一次營火晚會上，對著一群年輕猴子分享了在各部落的所見所聞。

第一站：真正敏捷的求生部落

我的第一站是在一個剛成立的求生部落，評審猿就是我們的首領。

評審猿總想要用最快的速度，拿到想要的東西，但他有一個優點，就是他知道不能又要馬兒跑、又不給馬兒吃草。

評審猿會明確告訴我們：『這週，唯一的目標，就是驗證新品種的芒果口味香蕉能不能吃！』 當我們全力以赴實現目標時，評審猿願意接受其他事情都延期，並且從不說我是成熟的大人，我兩個都要這種屁話，更重要的是評審猿想要的永遠都是真正可以吃的香蕉。

評審猿只負責決定大方向，但如何用最小的成本去驗證『這東西能不能吃』，是整個部落一起腦力激盪出來的，我們可能只是派一隻猴子去吃一口，而不是直接規劃一座芒果口味的果園。

在這個部落裡開發出來的東西，要嘛一直被使用，要嘛就是被更好的版本替換掉。從來沒有發生過花費巨大心力蓋了一座果園，結果裡面種的是不能吃的香蕉。

第二站：披著敏捷外皮的瀑布王國

我的第二站的部落，規模大了許多，有著一套看似完美的 Scrum 流程。

• 每天開 Daily Stand-up meeting
• 開 Daily 的時候還要合照回報到評審猿在的猴聯網群組
• 每兩週有 Retro (回顧會議)，寫了一堆看似有用的便利貼

但那是我待過最不敏捷的地方。為什麼？因為敏捷通常是為了應對不確定的需求，但那個部落的產品非常穩定，我們的敏捷之術，演變成一場大型的職場扮家家酒。

• 我們的 Retro 不聊產品方向，只聊大家的心情、誰家的猴寶寶很可愛。
• 我們的 Stand-up 只是輪流報流水帳，跟大家說我真的很忙。

因為早期驗證完，也根本沒人給你回饋，那或許一開始就朝著最終目標，用瀑布式開發走到底，不是更有效率嗎？

第三站：最理想的國度—瀑布與敏捷的共舞

我待的第三站部落，最有意思，絕大多數時候，需求明確時程固定。

程序猿們可以很安穩地專注在開發上，不用被頻繁變動的需求干擾。如果天外飛來一顆隕石，要嘛時程拉長，要嘛就砍掉一些功能，公平交易。

但是，一旦有探索新品種水果或開闢新種植場域這種高風險、高不確定性的任務時，團隊又能立刻切換成敏捷模式。快速打造最小可行性的產出、快速驗證、快速迭代，把資源精準地投在刀口上。

• 從程序猿能維持專注的角度，瀑布能讓你走得更穩
• 從產品能活下去的角度，敏捷能提高存活機率

如果可以，我會希望瀑布和敏捷交替進行。

• 想認真搞產品時，我們就敏捷。
• 想讓心力休息、專注在寫出好的程式時，我們就瀑布。

這，也許是心中最理想的環境。

別再執著於儀式，先問「我們為何而敏捷」

我也曾經天真地，想把敏捷的好處帶給那個瀑布王國，最後才發現，一個不需要敏捷的團隊，是不可能把敏捷跑好的。

你甚至可以反問：如果團隊真的不需要，那又何必強推呢？反而一個團隊很少開發出垃圾功能，這就是敏捷精神最好的象徵。

想通了這點，慢慢就開始能接受，大家把 Retro 和 Stand-up 搞得亂七八糟了。因為問題不在儀式，而在於他們打從心底，就不需要這趟探索未知的旅程。

你的團隊，比較像哪一個部落🐵